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20.  ABSTRACT 


Currently,  there  does  not  exist  a  certlflably  secure, 
multiuser  operating  system.  No  operating  system  has  been 
able  to  withstand  malicious  attacks  by  skilled  perpetrators. 
Nevertheless,  there  exists  a  strongly  felt  need,  both  in  the 
military  anc  civilian  sectors,  for  reliably  secure  operating 
system  software.  At  the  same  time,  any  solution  to  the 
security  problem  must  take  into  account  the  enormous 
investment  in  existing  equipment  and  software. 

Hypervisors  are  discussed  as  ar  approach  to 
retrofitting  security,  but  are  rejected  due  to  the  high  cost 
and  complexity  involved  In  their  installation  on  existing 
equipment.  An  alternative  solution,  encapsw 1  at i on,  is 
proposed  for  batch  and  RJE  systems.  It  involves  the  use  of 
a  small  amount  of  additional  hardware  and  verified  software. 
The  resulting  system  can  be  certified  to  be  secure,  and  is 
suitable  for  stringent  military  requirements.  The  solution 
is  applicable,  essentially  unchanged,  to  a  wide  class  of 
haruware  and  software,  and  it  is  Insensitive  to  special 
versions  of,  or  changes  to,  operating  system  code. 
Operating  efficiency  and  costs  of  construction  are  discussed 
In  this  paper  to  demonstrate  the  feasibility  of 
encapsu 1  at  I  on. 

This  work  has  been  performed  under  Aovanced  Research 
Projects  Acency  Contract  OAHC 1 5  72  C  0208.  It  is  part  of  a 
larger  effort  to  provide  securable  operating  systems  in  DOD 
envi ronments . 
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ABSTRACT 


Currently,  there  does  not  exist  a  certffiably  secure, 
multiuser  operating  system.  No  operating  system  has  been 
able  to  withstand  malicious  attacks  by  skilled  penetrators. 
Nevertheless,  there  exists  a  strongly  felt  need,  both  in  the 
military  anc  civilian  sectors,  for  reliably  secure  operating 
system  software.  At  the  same  time,  any  solution  to  the 
security  problem  must  take  into  account  the  enormous 
investment  in  existing  equipment  and  software. 

Hypervisors  are  discussed  as  an  approach  to 
retrofitting  security,  but  are  rejected  due  to  the  high  cost 
and  complexity  involved  in  their  installation  on  existing 
equipment.  An  alternative  solution,  encapsulation,  is 
proposed  for  batch  and  RJE  systems.  It  involves  the  use  of 
a  small  amount  of  additional  hardware  ano  verified  software. 
The  result} rg  system  can  be  certified  to  be  secure,  and  is 
suitable  for  stringent  military  requirements.  The  solution 
is  applicable,  essentially  unchanged,  to  a  wide  class  of 
hardware  and  software,  and  it  is  insensitive  to  special 
versions  of,  or  changes  to,  operating  system  code, 
operating  efficiency  and  costs  of  construction  are  discussec 

*  this  paper  to  demonstrate  the  feasibility  of 
encapsu 1  at i on. 

This  work  has  been  performed  under  Advanced  Research 
Projects  Agency  Contract  DAHC 1 b  12  C  0308.  It  is  part  of  a 

larger  effort  to  provide  securable  operating  systems  in  DGC 
env i r onments . 
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crtuted  with  security  as  a  major  design  |  arameter  are  easily 
penetrated.  In  general,  retrof i tti no  the  multi  pie  versions 

—  y^Ljotis  operating  systems  b*  revising  thei  r  code  j_s 
i mpract?  cal . 


Nevertheless,  the  security  problem  of  existing  systems 
is  important  and  will  not  disappear  in  the  coming  years. 
The  only  solution  now  available  to  those  installations 
requiring  protection  has  been  to  ccmpartmenta I i zei  to  have 
separate  operating  systems  for  each  security  category  or 
level.  For  the  military,  this  means  having  an  operating 
system  for  each  of  the  four  security  levels;  Unclassified, 
Confidential,  Secret,  and  Top  Secret.  For  tne  typical 
commer leal  installation,  this  might  mean  having  separate 
operating  systems  for  payroll,  accounts  receivable,  and 
general  computing.  Security  is  achieved  through  physical 
isolation,  hut  at  a  substantial  cost.  A  considerable  amount 
of  useful  machine  time  is  wasted  changing  systems  (often 
called  charging  "colors*1),  since  it  is  necessary  for  the 
existing  operating  system  to  be  shut  down,  all  storage 
either  physically  removed  or  written  over,  and  the  next 
system  Initiated.  For  some  installations,  a  single  change 
can  require  an  hour  or  more.  To  minimize  tost  time,  rigid 
schedules  must  be  established,  meaning  that  the  system  Is 
inflexible  to  the  needs  of  Its  users..  Also,  sharing  can 
only  be  achieved  through  off-line  procedures,  controlled 
admi ni strat i ve I y. 
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INTRODUCTION 


Over  the  past  few  years,  the  computino  community  has 
seer  a  st<aay  Increase  in  the  number  of  applications  using 
Information  that  must  be  protected  from  accidental, 
unauthor  I 20(  ,  or  malicious  use.  Today^s  multiuser  computer 
systems  should  be  able  to  provlce  this  protection  using  a 
comf  i  nat  i  on  of  hardware  ana  software  controls.  In  fact  the 
systems  are  unsatisfactory.  While  some  procress  is 
currently  being  made  in  the  constructive  oesign  of  new, 
secure  operatino  systems,  that  work  is  not  expected  to  bear 
practical  fruit  immediately.  In  the  meanwhi 1 e,  there 
currently  exist  large  numbers  of  disparate  computers  and 
operating  systems  for  which  security  is  an  important 
concern. 

F or  someone  skilled  in  the  art,  penetrating  toc«y-s 
operating  systems  takes  little  more  effort  than  solving  a 
hard  Suncay  crossword  puzzle,  and  it  can  be  considerably 
more  lucrative.  Retrofitting  these  systems,  in  the  general 
sense  of  repairing  the  respective  operating  systems  in  all 
their  varicus  versions,  is  an  enormous  task,  which  is  not 
well  understood.  To  date,  all  such  attempts  have  met  wi  th 
failure.  In  one  case,  several  million  dollars  was  spent  to 
create  a  multilevel  secure  version  of  an  existirg  operating 
system  only  to  have  the  result  quickly  breached  by  an 
outside  penetration  team.  Even  systems  that  have  been 
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A  solution  to  the  security  retrofit  problem  for  Latch 
and  RJE  cvstems  is  proposed.  It  is  fairly  simple,  appears 
econonu cal,  and  will  pr ov ioe  certifiable  security  across 
var i ous  marufacturers,  computers,  and  versions  of  operation 
systems.  Hat  is,  the  same  solution  may  be  erriplcyea, 
r  eqc  r  dl  ess  of  which  manu  f  ac  t  urer**s  equipment  is  involved  or 
what  particular  operating  system  version  or  modification  is 
being  run.  The  method  is  related  in  spirit  to  virtual 
machine  designs,  in  the  sense  of  CP-67,  VM/370  or  UCLA-VM 

[2,'<J. 

VIRTUAL  MACi  I NEb 

A  hypervisor,  or  virtual  machi ne  monitor,  is  a  program 
whose  task  is  to  provide  multiple  program  environments  that 
are  logically  identical  to  the  bare  hardware  or  which  the 
hypervisor  runs.  Normal  operating  systems,  of  course, 
provide  multiple  environments,  but  those  environments  have 
been  altered  from  that  of  the  original  bare  machine. 
Certain  capab i 1 i t i es ,  notably  resource  management  and  I/O 
instructions,  have  been  removed,  while  extensive  user 
services  have  been  added. 

Because  a  hypervisor  provides  few  services,  it  is  a 
much  simpler  program  than  an  operating  system.  Its  major 
tasKS  are  to  provide  separate  environments,  called  virtual 
machines,  and  to  simulate  the  behavior  of  instructions,  such 
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as  those  that  change  relocation  registers,  which  cannot  be 
performed  clrectly  by  programs  running  on  the  virtual 
machl ne. 

The  programs  run  on  virtual  machines  are  usually 
operating  systems,  which  In  turn  provide  the  needed  services 
for  conventional  user  programs.  Hypervisors  are  promising 
candidates  as  a  method  for  providing  security  via 
separation,  or  Isolation  of  users,  each  with  his  own 
operating  system  [4,5]. 

Virtual  machine  separation  is  not  obtained  without 
significant  costs.  Complex  simulation  of  I/O  is  a  necessary 
part  of  any  hypervisor  running  cn  a  third  generat I  on- like 
ar c h i t ec t ure.  This  simulation  of  all  sensitive  instructions 
slows  program  performance,  but  more  Important,  it  requires 
complexities  in  hypervisor  code  that  can  make  certification 
difficult,  at  least  at  present.  Furthermore,  some  existing 
architectures  do  not  have  the  c haracter i st i cs  necessary  to 
allow  v i r tua 1 i zat i on ,  and  so  machine-specific  hardware 
modifications  are  necessary  [3].  Finally,  a  hypervisor  must 
be  written  and  certified  for  each  model  of  the  hardware. 

While  the  intent  of  separation  is  promising,  rhe 
virtual  machine  approach  encounters  difficulties  in 
retrofitting  because  of  the  frequent  need  for  special 
naroware,  inefficiencies  due  to  complex  simulation,  and  the 
overall  complexity  of  the  hypervisor  code. 
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LNCAPSULATICN 


A  slmplier  approach  than  the  above  is  to  remove  the 
hypervisor  from  the  host  machine,  and  construct 
externally-enforced  user  separation  and  device  access 
controls  at  the  peripheral  devices,  rather  than  within  core 
memory.  Such  a  technique  both  removes  the  high  costs  of 
simulation,  and  eliminates  the  related  complexity  that  can 
make  virtual  machines  unattractive  from  the  point  of  view  of 
certification.  A  description  of  the  encapsulation  unit 
toll ows. 

To  a  currently  existing  configuration,  a  small 
minicomputer  is  added  that  controls  several  large  switches. 
These  switches  are  connected  a^_  the  devi  ce  to  tape  drives, 
disks,  and  ether  similar  units  of  original  equipment.  These 
switches  are  physically  placed  in  the  read/write  circuit  of 
the  devices  and  allow  the  mini  to  enable  or  oi  sable  these 
peripheral  cevices.  As  in  the  virtual  machi ne  case,  each 
encapsulatec  user  program  will  run  with  its  own  operating 
system.  Oependi ng  on  which  operating  system  is  currently  in 
control  of  the  production  CPU,  the  mini  sets  the  device 
switches  accordingly,  so  that  the  operating  system  can 
physically  access  only  those  devices  that  the  mini  has 
allowed.  For  many  existing  peripheral  devices,  these 
switches  are  already  present. 
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How  dot's  the  mini  know  which  operating  system  is 
running,  «n  d  how  are  operating  systems  switched?  The 
minicomputer  Is  connected  to  the  original  equipment  through 
an  I/O  port,  and,  in  addition,  controls  the  usual  hardware 
ciirectec  Initial  program  load  sequence  (IPL).  To  change 
operating  systems,  the  mini  initiates  IPL,  which  is  arranged 
to  load  a  boot  load  program  from  the  mini  through  the  I/O 
port.  This  bootload  program  first  copies  out  the  core  Image 
of  currently  operating  software.  Next,  the  mini  switches 
the  mooe  of  the  devices  connected  to  the  original  computer. 
Finally,  the  bootload  program  swaps  in  the  core  image  of 
another  operating  system.  The  swap  process  should  only  take 
a  few  seconds,  and  the  newly  loaded  system  can  continue 
running  immediately.  The  process  is  simple  and 
straightforward,  two  of  its  virtues. 

There  are  a  number  of  points  worth  making  about  the 
r.capsu  I  at  I  on  unit.  First,  all  mechanisms  and  code 
responsible  for  security  are  Isolated  in  the  minicomputer, 
leading  to  simplicity  anc  relative  ease  of  certification. 
Full  use  of  the  original  hardware  is  available  to  user 


oper at  I ng 

systems 

and 

appl  i 

1  cat i on 

programs.  The  complex 

si  mu  1  at I  on 

rout i nes 

of 

the 

vi r tual 

memory  approach  are 

el  I  mi nated. 

Second,  since  the  mini  has  an  I/O  port  to  the  original 
equipment,  it  may  well  be  practical  for  the  mini  to  control 
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spooling  of  input  and  output.  Currently  existing  I/C 
devices,  such  as  printers,  card  readers,  and  punches,  can  be 
disconnectec  from  the  original  hardware  and  connecteo  to  the 
mini.  In  this  way,  the  installation  obtains  spooling  at 
little  extra  cost,  and  hence  may  be  able  to  cut  down  on 
certain  other  expensive  resources.  Also,  if  operating 
systems  are  swapped  relatively  frequently,  this  variatior 
eliminates  the  necessity  of  switching  card  decks,  printer 
paper,  ribbons,  and  the  like  in  synchrony.  1  he  spooling 
requires  the  mini  to  have  its  own  disk  for  temporary 
storage. 

Third,  the  system  can  be  extended  to  allow  read-only 
sharing.  This  can  be  achieved  by  allowing  the  mini  to  set 
the  device  in  one  of  three  modes:  off,  read-only,  or 
read/write.  This  extension  enables  the  sharing  of  common 
operating  systems  and  libraries.  In  addition,  whenever  a 
partial  ordering  of  security  levels  exists,  a  level  n 
security  system  can  be  allowed  read-only  access  to  level  k 
disk  drive  spindles,  for  all  k  <  n.  Of  course  If  one 
operating  system  is  Interrupted  while  in  the  process  of 
updating  a  file  on  a  device  that  is  available  in  read-only 
mode  to  another  system,  that  second  system  uses  the  file  at 
its  own  risk.  This  situation  should  not  be  bothersome, 
since  in  many  installations  the  sharing  of  files  among 
operating  systems  is  used  primarily  with  regard  to  common 
code  and  data,  which  are  infrequently  updated.  As  a  further 
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refinement  to  the  disk  switch,  phys i ca 11 y- enforced 
mini-disks"  can  be  created  by  introducing  a  simple  cylinder 
address  relocation  register  setable  by  the  minicomputer. 

Fourth,  to  minimize  the  context  that  must  be  saved  and 
to  simplify  the  swapping  program,  operating  systems  should 
oniy  be  swapped  when  in  a  "standard  state".  Peripheral 
cevices  shoulc  be  in  a  quiescent  state,  and  any  registers  or 
aata  that  might  be  destroyed  in  the  bootload  process  should 
be  saved.  This  requirement  in  no  way  effects  the  security 
of  the  system.  If  a  s/stem  does  not  enter  the  "standard 
state"  before  being  swapped  out,  it  may  not  be  able  to  b< 
restarted  when  it  is  subsequ<ntly  swapped  in. 

Other  embellishments  might  include: 

•  A  hard  wired  bypass  switch  to  allow  peripheral  devices 
normally  connected  to  the  mini  to  be  connected  directly 
to  the  original  system  for  maintenance; 

•  A  crots-bar  •'witch  to  allow  periphere  s  to  be 

physically  cc  inected  to  different  I/O  por*  j  for  systems 
that  lack  hardware  or  operating  system  lexibility  in 
ass i gni ng  dev  cos ; 

•  Separate  operator's  consoles  attached  to  the  mini  for 
each  operating  system  for  ease  of  operation; 
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FIGURE  1.  SECURITY  ENCAPSULATION  UNIT 
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A  secur i i y  status 


panel  which  displays  the 


current 


security  ievel,  device  assignments,  etc.  of  the 
system. 

An  t  ncapsu  1  at  i  or  hardware  conf  f  gur  at  i  on  is  shown  in  Figure  1. 
HARDWARE  COSTS 

Hardware  costs  for  the  encapsu 1  at i on  unit  are  estimated 
to  be  approximately  $53,000.  Figures  below  are  based  on 


current  commercially  available 

equ i pment . 

1 

t  ini  Computer  CPU  with  1 6K  memory 

$11,400 

3 

Consoles  with  controllers 

$  6,000 

2 

Switches  with  bus  mounting 

$  900 

1 

Disk  wi tl  controller 

$1 1,000 

1 

High-speed  paper  tape  reader 

$  4,000 

(for  maintenance  of  mini) 

1 

Channel  Interface 

( est i mated) 

$10, 000 

1 

Channel  simulator 

( estimated) 

$10. 000 

approx. 

$53,000 

Not  included  in  the  hardware  cost  estimates  are: 

a)  remote  IPL  links; 

b)  mini  bypass  switch  for  I/O  devices 

(card  reader,  punch,  etc.); 

c)  security  status  panel. 
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SOFTWARE  COnS 


ErO£H_dI5  Ver  I  f  j  cat i on 

In  adcition  to  the  hardware,  the  code  in  the 
minicomputer  that  makes  security  decisions  must  be  proven 
correct.  Security  assertions  must  be  constructed  and 
program  verification  techniques  applied.  The  task  requires 
a  significant  effort,  but  it  is  essentially  a  one-time  cost. 
The  amount  of  code  that  muse  be  verified  is  of  a  size  ano 
order  of  complexity  within  tht  limits  of  already 
demonstratec  ability.  Roughly  two-man  years  of  work  by 
highly  competent  professional  personnel  is  required  to 
perform  the  necessary  proofs,  given  the  state  of  currently 
available  verification  support  tools  [1],  Thus,  the 
construction  of  the  necessary  verified  mi ni ccmputer  code  is 
a  practical  task. 

Qper at i nq  System  Modi f i cat i on 

8ecause  of  certain  practical  considerations,  additional 
software  costs  may  result  from  modification  of  the  original 
operating  system.  These  modi f i cat i ons  fall  into  two 
categories*  those  necessary  for  system  quiescence,  and  those 
for  read-only  sharing. 

As  stated  previously,  systems  should  be  swappec  when  in 
a  "standarc  state"  to  minimize  the  context  that  must  be 
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saved  by  the  bootload  program.  Thus,  the  operating  system 
must  be  moeified  to  include  routines  to  quiesce  and  restore 
1/0  and  to  save  and  restore  registers  or  data  that  would  be 
oestroyed  in  the  bootload  process.  For  most  operating 
systems,  this  modi f icati  on  is  trivial.  In  GS/360,  for 
example,  the  only  changes  necessary  are  the  inclusion  of  a 
software  setable  switch  which  is  tested  in  the  channel 
restart  routine,  and  a  small  routine  to  save  ano  restore  the 
first  few  words  of  memory. 

Software  modifications  may  also  be  necessary  to  support 
reaa-only  sharing.  The  system  must  include,  or  be  modified 
to  include,  the  ability  to  control  the  allocation  of  logical 
files  on  physical  devices.  Otherwise  the  system  might  try 
to  allocate  a  file  on  a  read-only  peripheral.  Also,  some 
operating  systems,  such  as  DEC  10/50,  Tenex,  and  GCOS, 
require  write  access  to  all  peripherals  since  they  store 
information  such  as  the  date  of  last  read  and  read-only  lock 
bits  with  the  physical  file.  This  software  would  have  to  be 
cisabled  for  read-only  peripherals  in  these  systems. 

OPERATING  COSTS 

There  will  be  some  lost  storage  on  the  original 
equipment  due  to  duplication  of  some  operating  system  code 
and  data.  In  addition,  if  a  job  of  a  given  security 
c  1  as s i f i cat i on  needs  more  I/O  units  than  are  currently 
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dedicated  to  It,  manual  changes  may  be  required,  slowing  the 
swap  betweei  systems  and  wasting  computer  time. 

COST  GAINS 

There  are  a  number  of  cost  savi ngs. 

1.  Spool  Inc  may  be  provided  nearly  free. 

2.  More  freedom  is  gained  in  scheduling.  An  operating 
system  runring  at  level  x  can  be  interrupted  for  a  high 
priority  Job  of  level  y  where  y  £  x. 

3.  The  security  provided  by  encapsulation  is  Insensitive  to 
operating  system  type  or  version.  Installation 
modi  f  l  cat  i  or  s  or  updates  can  be  r.iaoe  freely  and  have  no 
effect  on  the  security  of  the  system. 

A.  Once  a  machine  has  been  secured  for  a  given  operating 
system,  the  incremental  cost  for  securing  a  ai fferent 
operating  system  for  that  same  machine  is  small,  limited  to 
the  chances  mentioned  above  in  Operating  System 
Modification.  So,  for  example,  after  an  installation  has 
encapsulated  IBM's  OS/360,  securing  IBM's  DOS/360  is  likely 
to  be  inexpensive. 
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CL  INCLUSION 


Encapsi  1  at  i  on  provides  many  of  the  benefit,  of  the 
virtual  machine  approach,  without  most  of  the  headaches 
involveo  in  retrof i tti ng,  anc  the  cost  appears  economical. 

The  usual  lost  time  currently  devotee  to  scrubbing  one 
level  security  system  to  prepare  for  another  is 
c  i gr i f I  cant  1 y  decreased.  Most  important  however, 

enca£suJ_aU_cn  provides  a  certifiable.  reliable  means  for 
i  level  computer  securi  ty  on  exi  sti  no  systems.  possibly 
end?  eg  the  retrofit  problem. 
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